…r-bailout pitfall

The previous implementation depends on React's useState eager-bailout fast
path in dispatchSetStateInternal:

  if (fiber.lanes === NoLanes && (alternate === null || alternate.lanes === NoLanes)) {
    // eager bailout — drop the update without scheduling a render
  }

The fiber passed is the one bound at mount. After the first listener-driven
render commits, that fiber becomes the alternate of the new current — but its
.lanes is never cleared from the enqueueUpdate that preceded the render.

From that point on, every subsequent listener dispatch fails the NoLanes
precondition. Updates are queued normally, schedule a render, and the reducer
runs in-render only to return prevState. React then calls
bailoutOnAlreadyFinishedWork — the DOM doesn't update, but the component
function already executed. This is the "Glitchy Behavior" documented in the
context-selector-tearing RFC.

New implementation:
- Reads valueRef.current during render (like useSyncExternalStore's getSnapshot).
- No [value, selected] state tuple. No setState(prev => prev) trick.
- useReducer(x => x + 1) as opaque force-update counter.
- Listener compares selector(newValue) against lastReturnedRef and forces only
  when the slice actually differs.
- Layout-effect fixup per Relay's useFragmentInternal pattern.

Preserves: public API, listener payload shape ([version, value]),
useHasParentContext behavior, Level 1 tearing behavior.

See RFC PR for the full Option D writeup.

…ive-deps

The react-compiler rule errors when react-hooks rules are disabled, and
exhaustive-deps doesn't actually complain about the effect's deps (both
listeners and valueRef are referentially stable context fields).

…ssion tests

Addressing code review feedback on #36002:

1. [BLOCKER] Restore try/catch around selector calls in both the listener
   and the effect-fixup. The previous implementation wrapped the selector in
   a try/catch with the comment 'ignored (stale props or some other reason)'.
   The new hook dropped that guard; since the provider iterates listeners
   with Array.prototype.forEach which aborts on throw, any consumer whose
   selector throws on an intermediate payload would silently starve all
   later subscribers of that update. Restoring the guard preserves the
   prior isolation contract.

2. Add an inline comment explaining why the new hook destructures only
   { value, listeners } from the context and ignores the version field.
   The version is still maintained by the provider and consulted by
   useHasParentContext as a parent-presence sentinel; it is no longer
   needed as a staleness guard because the provider fires listeners
   synchronously inside useIsomorphicLayoutEffect, and freshness is
   guaranteed by the effect-fixup.

3. Add regression tests:
   - 'memoized consumers re-render only when their selected slice changes':
     the RFC's Scenario 2 with React.memo'd items, asserting per-item
     onUpdate call counts across a cycling sequence. Catches the
     'three items re-rendered instead of two' glitch if it regresses.
   - 'a single consumer throw does not starve later subscribers of
     context updates': exercises the listener error-isolation path
     restored above.

StrictMode sanity-checked locally: layout-effect mount → cleanup → mount
in dev produces idempotent ref re-assignments and no extra forceUpdate()
calls — render counts scale by React's dev-mode 2x factor as expected,
with no pathological churn.